A Framework for Automatic

Plan Less abstract search Figure 1: The results of abstract problem-solving can serve to constrain search in more detailed spaces. Here, abstract operations are used to constrain information about which more detailed operations are considered at a search point. search. The utility of an abstraction mapping is that information obtained by less expensive problem-solving in an abstract space can then be used to guide the problem-solving in a corresponding ground space, thus reducing | sometimes exponentially | the combinatorics of the task. Figure 1 suggests this process. 2 Impasse-Driven Abstraction In this section, we describe a problem-solving framework called Spatula, which uses abstraction to help it make planning decisions. Whenever the system is at an impasse | a choice point in the planning process | it uses abstractions, automatically and dynamically generated from its given domain theory, to search for and learn a reactive abstract plan. The system does not need to use abstract search if it is not at an impasse, since then it already knows which action(s) to take next. The system uses multiple levels of abstraction, where, as in Figure 1, the plan at each level is used to guide and reduce the combinatorics of the next more detailed plan expansion. Spatula's framework may be instantiated with di erent parameterized abstraction methods, which produce varying abstraction planning behavior. In this section, we describe the framework in general terms, by describing the pieces that support the impasse-driven abstraction behavior, and showing how the pieces t together into an integrated framework for abstract planning. Then, in Section 3, we discuss speci c instantiations of several abstraction methods within this framework. 2.1 Dynamic Precondition Abstraction The basis for abstraction in Spatula is a technique for dynamic precondition abstraction. The technique allows the problem solver to create an abstract planning space from a ground-level space by dynamically abstracting (ignoring) operators' unmet preconditions, thus generating a shallower and less expensive search. The space of possible abstractions, based on unmet preconditions for a particular context, is problem-dependent. The basis method, as well as other techniques for abstracting preconditions (e.g., ABStrips [22]) belongs to the class of Proof-Increasing Abstractions [11, 12]. For such abstractions, if a ground solution exists, it is guaranteed that there always exists some abstract solution such that the ground solution may be constructed by monotonically adding steps to the abstract solution. When operator preconditions are abstracted using Spatula's basis method, partial operator application will occur if there is not enough state information for the operator to apply completely. The framework's ability to dynamically abstract its domain operators in this manner is supported by a technique for representing the problem domain called factorization. Factorization represents components of a problem domain (operators, goal tests, etc.) in terms of the independent sub-parts which compose them. Factorization, and the basis precondition technique, are described in more detail in [24, 26]. 2.2 Abstract Plan Generation using Impasse-Driven Abstraction In this section, we describe Spatula's general algorithm, which uses its technique for precondition abstraction to construct and choose among abstract plans. The general algorithm is implemented within the Soar problem-solving architecture [18], and motivated by its capabilities. In Soar, problems are solved by search in problem spaces, in which operators are applied to yield new states. Long-term knowledge is represented in the form of rules. Inadequate knowledge about how to proceed in a situation produces an impasse, which the system tries to resolve by problem solving in a subgoal generated to resolve the impasse. Further subgoals may be recursively generated. A control impasse is an impasse that occurs when more than one option exists for the problem solver's next action, and it does not know which to choose next. The system's planning behavior occurs within the context of control impasses. Learning occurs in Soar by converting the results of subgoal-based search into new search-control rules; the system will use this new knowledge to decide what to do in relevantly similar situations. The learned search control thus constitutes a reactive plan. Soar's learning technique is a type of explanation-based learning [20, 17]. Spatula is an incremental addition to Soar. It adds information to Soar about how to abstract, and when to perform abstract search in reaction to control impasses (the abstraction methods); Soar learns abstract rules (the plan) from those searches. The abstraction methods work in conjunction with the system's search methods and domain knowledge to produce abstract problem-solving behavior. Figure 2 describes this process in pseudo-code, where select plan is invoked at a control impasse. Using select plan, the system will generate an abstract plan to guide its next actions. S, the best set of operators from which to choose the operator to apply next, is determined by the system's existing search control. The gure shows that the system is instantiated with a given abstraction method, abs method . This abstraction method determines which operators' unmet preconditions are abstracted to create an abstract plan, and may utilize information about the problem-solving context to do so. Section 3 will de ne the concept of abstraction methods and discuss the implementation of several such methods within Spatula. Here, it is only necessary to understand that using the given abstraction method, an abstract plan is generated from recursive search to build abstract sub-plans | the apply abstractly? predicate uses the method to determine whether a particular operator's preconditions will be abstracted1. As each best abstract operator (sub-)sequence is selected, search control is learned for those operators, adding to the abstract plan. The stop planning test halts search if it reaches a given maximum depth. 1The algorithm in the gure is slightly simpli ed for readability. To conduct a search in which global task goals are considered, more planner state information is utilized in generating the recursive call. select_plan(current_state, current_goals, planner_state, abs_method) { if (stop_planning(abs_method, current−state) or empty(current_goals)) return empty plan; S = best set of ops that achieve a goal in current_goals; for each op in S { // compute the best plan asociated with op if (apply_abstractly?(abs_method, planner_state) or op has no unmet preconditions in current_state) // add the operator to the current plan: apply abstractly // if unmet preconditions subplan = {op}; else { // do not abstract: achieve preconditions of operator subgoals = preconds of op; // add the plan to achieve (some of the) preconds, then the operator subplan = select_plan(current_state, subgoals, increment_level(planner_state), abs_method) + op; } // endif new_state = apply(subplan, current_state); new_goals = current_goals − goals achieved in current_state; // now compute the new plan associated with the operator if (empty(new_goals)) // if there are no more goals, stop with this plan op.plan = subplan;